This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
It is relatively common for software providers to protect the confidentiality of computer program software code. One reason is that the code comprises secret knowledge. Another reason is that the code was complex and costly to develop and that the developers want to hinder others from copying parts of the code for insertion in their programs. A further reason is that the developers wish to keep hackers from understanding the software as a pre-emptive defense against attacks.
A basic method of protecting confidentiality is to use encryption. The code is encrypted after the link at build time and decrypted at load time or during execution at running time. This solution works very well if a so-called cryptoprocessor is used to ensure confidentiality. Such processors are however both expensive, slow and not wide-spread.
Encryption works in a slightly different manner on a generic processor. It is, for example, normally not possible to encrypt the entire program code as at least one part (called the loader) of the code must be kept unencrypted in order to provide decryption of the remainder. On a generic processor, encryption provides good protection against static attacks, but it is vulnerable to dynamic analysis, as will be seen.
A further solution is obfuscation, see e.g. Christian Collberg and Clark Thomborson. Watermarking, Tamper-Proofing, and Obfuscation—Tools for Software Protection, IEEE Transactions on Software Engineering 28:8, 735-746, August 2002. Obfuscation may be said to comprise complicating the code so that it is difficult to understand. It provides good protection against static analysis, but it is very weak against dynamic analysis. In essence, obfuscation merely aims to slow down a hacker's work. Moreover, program performances decrease with obfuscation efficiency.
A typical attack on encrypted code is dynamic analysis: the code is dumped during execution since the code must be deciphered to be executed, which means that the executed code may be analysed.
A first technique to improve the security of code encryption is to decrypt only a small chunk of code, execute the decrypted code and then re-encrypt the chunk of code. This means that decrypted code is present in the memory only during a short time. However the implementation of this protection often comprises decrypting the code at an address chosen by the compiler. If an attacker detects encrypted code, it is easy to use a hardware breakpoint, execute the code and dump it when the hardware breakpoint is reached.
The inventors have provided a countermeasure in EP2075728, which describes a solution in which each code chunk is decrypted in a randomly selected address in the memory. The countermeasure makes it more difficult for an attacker to use breakpoints in the deciphered code: even if a breakpoint provides information about a protected function during one execution, the function will be executed at a different address the next time, which makes it more difficult to analyse the function.
However, the arrival of new tools—see e.g. Danny Quist and Lorie Liebrock. Reverse Engineering by Crayon, Game Changing Hypervisor Based Malware Analysis and Virtualization. Blackhat USA 2009—allows building huge execution traces. It is thus possible to find some pattern in the trace that corresponds to the execution of the encrypted code chunk. In the trace, the attacker can then notice that a particular module is executed before each execution of the encrypted chunk of code. This module is the decryption module, identification of it is a significant advance for the attacker: a breakpoint at the end of the decryption module enables dumping each encrypted code chunk before its execution.
It will thus be appreciated that there is a need for a solution that provides an improved protection of encrypted software code that makes it more difficult to analyse execution traces. The present application provides such a solution.